The following abbreviations are herewith defined, at least some of which are referred to in the following description associated with the prior art and the present invention.
ARPAddress Resolution ProtocolASICApplication Specific Integrated CircuitCPUCentral Processing UnitGREGeneric Routing Encapsulation ProtocolIPInternet ProtocolMACMedia Access ControlMPLSMulti-Protocol Label SwitchVLANVirtual Local Area NetworkVPNVirtual Private Network
In the communications field, it is common for switches to utilize a routing tunnel to route packets between two networks that are connected to one another through a common network. Typically, the switch utilizes the routing tunnel by encapsulating a layer 3 protocol packet (e.g., IPv4, IPv6, IPX) into another layer 3 protocol packet and then forwarding the encapsulated packet to the other switch through the common network. Two exemplary scenarios in which routing tunnels have been used are discussed next with respect to FIGS. 1 and 2 (PRIOR ART).
Referring to FIG. 1 (PRIOR ART), there is a diagram which is used to help explain one scenario where a routing tunnel 102 is used to route packets between two networks 104a and 104b (which both implement one protocol) through a common network 106 (which implements a different protocol). In this scenario, assume there are two IPv6 networks 104a and 104b (networks A and B) which respectively have two IPv6 switches 108a and 108b that are connected to one another via an IPv4 internet 106. In this case, the two IPv6 switches 108a and 108b can use an IPv6 over IPv4 tunnel 102 to transport packets to each other through the IPv4 network 106.
Referring to FIG. 2 (PRIOR ART), there is a diagram which is used to help explain another scenario where a routing tunnel 202 is used to route packets between two networks 204a and 204b (which both implement one protocol) through a common network 206 (which implements the same protocol). In this scenario, assume there is a company which has two IPv4 networks 204a and 204b (networks A and B) and wants to create a VPN so they can securely connect their two IPv4 networks 204a and 204b together through a public IPv4 internet 206. To accomplish this, the company would use two IPv4 switches 208a and 208b that can set-up an encrypted IPv4 tunnel 202 to securely transport packets through the public IPv4 internet 206.
These two exemplary scenarios and other scenarios can be easily implemented if the two switches 108a, 108b, 208a and 208b have ASICs (hardware) therein that were designed to support the particular type of routing tunnel 102 and 202. However, it is common that a “new” tunnel type be defined and implemented but is not supported by the “old” ASICs within the switches 108a, 108b, 208a and 208b. In this situation, the switches 108a, 108b, 208a and 208b will either not support the new routing tunnel or they will need to use software (i.e., CPU) to support the new routing tunnel. The former is not desirable because no new routing tunnels would ever be used by the switches. The later is not desirable because it can take a lot of CPU processing time within the switches to support a new routing tunnel. A detailed discussion is provided next about how a switch can support a new routing tunnel completely within software (i.e., the CPU).
Referring to FIG. 3 (PRIOR ART), there is a block diagram which is used to help explain how a traditional switch 300 implements a “new” routing tunnel completely within software when the “old” ASIC does not support the “new” routing tunnel. As shown, the traditional switch 300 includes an ASIC 302 which has ports 304, an IP routing logic unit 306, a routing/ARP table 308, an interface table 310 and an egress packet logic unit 312. In addition, the traditional switch 300 includes a CPU 314 which has a device driver 316, an IP protocol stack 318, a routing/ARP table 320 and an interface table 322. The steps associated with how the traditional switch 300 implements a “new” routing tunnel completely within software (i.e., the CPU 314) are as follows:
1-2. One of the ports 304 receives a packet 324 and recognizes that the packet 324 is a routed IP packet 324 and as a result forwards the packet 324 to the IP routing logic unit 306. FIG. 4A (PRIOR ART) is a diagram illustrating the different fields of the exemplary packet 324 which include a “Destination MAC” field 402 (containing a Router MAC address for ingress VLAN), a “Source MAC” field 404 (containing a source MAC address), a “Protocol Type” field 406 (containing 0x800 which indicates that the packet 324 is an IP packet 324) and an “Original IP Header” field 408 (note: the original packet 324 also contains additional fields 410 but these particular fields 410 are not relevant to the present discussion).
3-5. The IP routing logic unit 306 receives the packet 324 and then takes the destination IP address in the “Original IP Header” and performs a table lookup in the routing/ARP table 308 and learns that the packet 324 is to be routed in a new tunnel which is not supported by the hardware (i.e., the ASIC 302). In this situation, the IP routing logic unit 306 forwards the packet 324 to the CPU 314 and in particular the device driver 316 so that the packet 324 can be routed completely within the software of the switch 302.
6. The device driver 316 (packet dispatcher 316) receives the packet 324 and forwards that packet 324 to the IP protocol stack 318.
7. The IP protocol stack 318 upon receiving the packet 324 takes the destination IP address in the “Original IP Header” and performs a first table lookup in the routing/ARP table 320 to determine the egress interface (tunnel header information) of the packet 324 and in this example the egress interface happens to be a GRE tunnel (note 1: many other types of new tunnels in addition to the GRE tunnel such as a MPLS tunnel can be supported within software) (note 2: the first table lookup does not include an ARP lookup).
8. The IP protocol stack 318 reformats the packet 324 such that the re-formatted packet 326 has the tunnel header information placed in a new “Tunnel IP Header/GRE” field 412 while the “Destination MAC” field 402, the “Source MAC” field 404 and the “Protocol Type” field 406 are all removed therefrom. FIG. 4B (PRIOR ART) is a diagram illustrating the different fields of an exemplary re-formatted packet 326 which include a “Tunnel IP Header/GRE” field 412 and an “Original IP Header” field 408′ (note 1: the TTL is decremented within the “Original IP Header” field 408′) (note 2: the re-formatted packet 326 also contains the additional fields 410).
9. The IP protocol stack 318 then takes the re-formatted packet 326 and in particular the IP destination address from the “Tunnel IP Header/GRE” field 412 and performs a second table lookup within the routing/ARP table 320 and the interface table 322. In response to the second table lookup, the IP protocol stack 310 receives the destination MAC address and the egress port identifier from the routing/ARP table 320 and also receives the source MAC address and the VLAN identifier from the interface table 322.
10. The IP protocol stack 318 reformats the packet 326 such that the second re-formatted packet 328 has added thereto the destination MAC address, the source MAC address and the VLAN information. FIG. 4C (PRIOR ART) is a diagram illustrating the different fields of an exemplary second re-formatted packet 328 which includes a “Next Hop MAC” field 414 (containing the destination MAC address), a “Router MAC for Egress VLAN” field 416 (containing the source MAC address), a “Protocol Type” field 406′ (containing 0x800 which indicates that the packet 328 is an IP packet 328), a “Tunnel IP Header/GRE” field 412 and an “Original IP Header” field 408″ (note 1: the TTL is decremented within the Original IP Header field 408″) (note 2: the second re-formatted packet 328 also contains the additional fields 410) (note 3: the VLAN information is used when forwarding the second re-formatted packet 328).
11. The IP protocol stack 318 routes the second re-formatted packet 328 to the device driver 316 (packet dispatcher 316).
12. The device driver 316 (packet dispatcher 316) routes the second re-formatted packet 328 to the egress packet logic unit 312 (which is located within the ASIC 302).
13-14. The egress packet logic unit 312 routes the second re-formatted packet 328 to the correct egress port 304 which then forwards the second re-formatted packet 328 from a specific tunneled interface on a specific egress path to the next switch 108b (for example) which de-tunnels the second re-formatted packet 328.
This is how the traditional switch 300 can implement a “new” routing tunnel completely within the software (i.e., the CPU 314) when the “old” ASIC 302 does not support the “new” routing tunnel. However, this way is not that efficient because the IP Protocol Stack 318 has to perform two table lookups (see steps 7 and 9) and also has to reformat packet 324 into packet 326 and then reformat that packet 326 into packet 328 (see steps 8 and 10). This is not an efficient use of CPU processing time especially if the IP Protocol Stack 318 has to perform steps 7-10 for a very large number of packets. Thus, there is a need for a switch that can more effectively implement a “new” routing tunnel when the “old” ASIC does not support the new routing tunnel. This need and other needs are satisfied by the present invention.